Class method or Object method?

Hi

In general is it better to use a class method or object method? E.g I have a
class A which provides certain functionality. I just want to use one of its
methods in another class B. Is it better to inistantiate class A and do and
object call or just do A->myMethod() ? The method doesn't need a reference
to itself passed in so from that point of view it doesn't matter

Thanks

Justin
--
View this message in context: http://www.nabble.com/Class-method-or-Object-method--tp21732 172p21732172.html
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: Class method or Object method?

kropotkin wrote:

> In general is it better to use a class method or object method?

It depends on what you're using it for and how. Does the method act on any instance specific state
data? Or does it act on class specific data?

A more concrete example would be a Dog class. Is bark() a method on Dog or $fido? Well, every dog,
no matter it's name is going to bark the same. Is eat() a method on Dog or $fido? Well, if eat()
changes $fido's next_poop_interval property, then obviously it needs to be an instance method.

And of course, if your system is only every going to have 1 Dog then you don't need to ever have
instances, right?

--
Michael Peters
Plus Three, LP

Re: Class method or Object method?

It depends. (always the expected answer with an OOP design question =)

Generally, if the method you are calling on class A does not work
on/effect the state of a specific object, its a canidate to be a
static (class) method. However, you should be careful about coupling
your objects and understand what you are doing when you do. If you
feel comfortable for that method be a static method, though, you're
probably good to do so. Generally....depending....

=)

Hope this helps.

Steve

On Thu, Jan 29, 2009 at 12:54 PM, kropotkin wrote:
>
> Hi
>
> In general is it better to use a class method or object method? E.g I have a
> class A which provides certain functionality. I just want to use one of its
> methods in another class B. Is it better to inistantiate class A and do and
> object call or just do A->myMethod() ? The method doesn't need a reference
> to itself passed in so from that point of view it doesn't matter
>
> Thanks
>
> Justin
> --
> View this message in context: http://www.nabble.com/Class-method-or-Object-method--tp21732 172p21732172.html
> Sent from the mod_perl - General mailing list archive at Nabble.com.
>
>

Re: Class method or Object method?

Michael Peters wrote:
> kropotkin wrote:
>
>> In general is it better to use a class method or object method?
>
> It depends on what you're using it for and how. Does the method act on
> any instance specific state data? Or does it act on class specific data?
>
> A more concrete example would be a Dog class. Is bark() a method on Dog
> or $fido? Well, every dog, no matter it's name is going to bark the
> same. Is eat() a method on Dog or $fido? Well, if eat() changes $fido's
> next_poop_interval property, then obviously it needs to be an instance
> method.
>
This is a great example. :-)

> And of course, if your system is only every going to have 1 Dog then you
> don't need to ever have instances, right?
>
if ($Dog::is_female()) {
err on the side of caution && instantiate it nevertheless;
}

Re: Class method or Object method?

Hi

My class doesn't poop. period.



Michael Peters wrote:
>
> kropotkin wrote:
>
>> In general is it better to use a class method or object method?
>
> It depends on what you're using it for and how. Does the method act on any
> instance specific state
> data? Or does it act on class specific data?
>
> A more concrete example would be a Dog class. Is bark() a method on Dog or
> $fido? Well, every dog,
> no matter it's name is going to bark the same. Is eat() a method on Dog or
> $fido? Well, if eat()
> changes $fido's next_poop_interval property, then obviously it needs to be
> an instance method.
>
> And of course, if your system is only every going to have 1 Dog then you
> don't need to ever have
> instances, right?
>
> --
> Michael Peters
> Plus Three, LP
>
>
>

--
View this message in context: http://www.nabble.com/Class-method-or-Object-method--tp21732 172p21733591.html
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: Class method or Object method?

--000e0cd147dca9ca330461a3d0b6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I really like this example too, though it lacks a class method example:

if(DOG::number_of_dogs_in_the_pound() > 1){
foreach my $dog (@Pound){
if($dog->is_male()){
print "I though so";
}
}
}

Sorry, I couldn't resist after that female comment.

Marilyn

On Thu, Jan 29, 2009 at 10:56 AM, Andr=E9 Warnier wrote:

> Michael Peters wrote:
>
>> kropotkin wrote:
>>
>> In general is it better to use a class method or object method?
>>>
>>
>> It depends on what you're using it for and how. Does the method act on a=
ny
>> instance specific state data? Or does it act on class specific data?
>>
>> A more concrete example would be a Dog class. Is bark() a method on Dog =
or
>> $fido? Well, every dog, no matter it's name is going to bark the same. I=
s
>> eat() a method on Dog or $fido? Well, if eat() changes $fido's
>> next_poop_interval property, then obviously it needs to be an instance
>> method.
>>
>> This is a great example. :-)
>
> And of course, if your system is only every going to have 1 Dog then you
>> don't need to ever have instances, right?
>>
>> if ($Dog::is_female()) {
> err on the side of caution && instantiate it nevertheless;
> }
>
>
>

--000e0cd147dca9ca330461a3d0b6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I really like this example too, though it lacks a class method example:
=

if(DOG::number_of_dogs_in_the_pound() > 1){
    fo=
reach my $dog (@Pound){
        if($d=
og->is_male()){
         =
;   print "I though so";

        }
    }
} r>
Sorry, I couldn't resist after that female comment.

Marily=
n

Re: Class method or Object method?

Hi Steven

The method doesn't effect the state of anything . It just returns some
information. The context is:
class A is the Catalogue and B is the Cart. Usually they are separate but I
want to show a flag relating to the basket/cart in the catalogue against
each product. Really I am putting the method in the Cart class because it
seems to logically belong there - for organisational reasons. I see what you
mean about coupling though. It could get messy!

Regards

Kropotkin





Steven Siebert wrote:
>
> It depends. (always the expected answer with an OOP design question =)
>
> Generally, if the method you are calling on class A does not work
> on/effect the state of a specific object, its a canidate to be a
> static (class) method. However, you should be careful about coupling
> your objects and understand what you are doing when you do. If you
> feel comfortable for that method be a static method, though, you're
> probably good to do so. Generally....depending....
>
> =)
>
> Hope this helps.
>
> Steve
>
> On Thu, Jan 29, 2009 at 12:54 PM, kropotkin
> wrote:
>>
>> Hi
>>
>> In general is it better to use a class method or object method? E.g I
>> have a
>> class A which provides certain functionality. I just want to use one of
>> its
>> methods in another class B. Is it better to inistantiate class A and do
>> and
>> object call or just do A->myMethod() ? The method doesn't need a
>> reference
>> to itself passed in so from that point of view it doesn't matter
>>
>> Thanks
>>
>> Justin
>> --
>> View this message in context:
>> http://www.nabble.com/Class-method-or-Object-method--tp21732 172p21732172.html
>> Sent from the mod_perl - General mailing list archive at Nabble.com.
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Class-method-or-Object-method--tp21732 172p21733697.html
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: Class method or Object method?

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--373334887-28721671-1233257336=:910
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID:



On Thu, 29 Jan 2009, Marilyn Burgess wrote:
> I really like this example too, though it lacks a class
> method example:
>
> if(DOG::number_of_dogs_in_the_pound() > 1){
>   =A0 foreach my $dog (@Pound){
>       =A0 if($dog->is_male()){
>           =A0 print "I though so";
>       =A0 }
>   =A0 }
> }
>
> Sorry, I couldn't resist after that female comment.
>
> Marilyn

Hrmm.

my $kennel =3D Kennel->new('spca-1');
$_->bark for grep $_->gender eq 'male', $kennel->get_dogs;

Michael Peters wrote:
> And of course, if your system is only every going to have
> 1 Dog then you don't need to ever have instances, right?

IMHO, project managers tend to tell you things like that,
and then then tell you they have another dog. I find it a
generally good idea to start with object models from the
beginning. And if your objects need to be persistent and
have storage associated with them, start with DBIx::Class
from the beginning, don't try to add that later after you've
written "simple" data getters/setters. ;-)

Mark
--373334887-28721671-1233257336=:910--

Re: Class method or Object method?

If I am reading your situation correctly, you want to be able to
reference the catalogue for product information from the cart?

If this is the case, perhaps the cart should be a container for
"PurchaseItem" objects which contain the essential data (ie price,
weight) and behaviours (calcShippingCost(), calcTax(),
getProductInfo() - the last which can pull the reference from your
catalogue). Additional information about the PurchaseItem can be
"lazy loaded" from the catalogue if needed (ie product description) to
keep your PurchaseItem lite and purpose-oriented. As an added bonus,
by containing the PurchaseItems within the cart you can easily provide
convience methods to iterate over the collection for things like
calculating the total weight, total price, etc.

Regards,

S

On Thu, Jan 29, 2009 at 2:11 PM, kropotkin wrote:
>
> Hi Steven
>
> The method doesn't effect the state of anything . It just returns some
> information. The context is:
> class A is the Catalogue and B is the Cart. Usually they are separate but I
> want to show a flag relating to the basket/cart in the catalogue against
> each product. Really I am putting the method in the Cart class because it
> seems to logically belong there - for organisational reasons. I see what you
> mean about coupling though. It could get messy!
>
> Regards
>
> Kropotkin
>
>
>
>
>
> Steven Siebert wrote:
>>
>> It depends. (always the expected answer with an OOP design question =)
>>
>> Generally, if the method you are calling on class A does not work
>> on/effect the state of a specific object, its a canidate to be a
>> static (class) method. However, you should be careful about coupling
>> your objects and understand what you are doing when you do. If you
>> feel comfortable for that method be a static method, though, you're
>> probably good to do so. Generally....depending....
>>
>> =)
>>
>> Hope this helps.
>>
>> Steve
>>
>> On Thu, Jan 29, 2009 at 12:54 PM, kropotkin
>> wrote:
>>>
>>> Hi
>>>
>>> In general is it better to use a class method or object method? E.g I
>>> have a
>>> class A which provides certain functionality. I just want to use one of
>>> its
>>> methods in another class B. Is it better to inistantiate class A and do
>>> and
>>> object call or just do A->myMethod() ? The method doesn't need a
>>> reference
>>> to itself passed in so from that point of view it doesn't matter
>>>
>>> Thanks
>>>
>>> Justin
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Class-method-or-Object-method--tp21732 172p21732172.html
>>> Sent from the mod_perl - General mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Class-method-or-Object-method--tp21732 172p21733697.html
> Sent from the mod_perl - General mailing list archive at Nabble.com.
>
>

Re: Class method or Object method?

Throw a dog a bone...





Michael Peters wrote:
>
> kropotkin wrote:
>
>> In general is it better to use a class method or object method?
>
> It depends on what you're using it for and how. Does the method act on any
> instance specific state
> data? Or does it act on class specific data?
>
> A more concrete example would be a Dog class. Is bark() a method on Dog or
> $fido? Well, every dog,
> no matter it's name is going to bark the same. Is eat() a method on Dog or
> $fido? Well, if eat()
> changes $fido's next_poop_interval property, then obviously it needs to be
> an instance method.
>
> And of course, if your system is only every going to have 1 Dog then you
> don't need to ever have
> instances, right?
>
> --
> Michael Peters
> Plus Three, LP
>
>
>

--
View this message in context: http://www.nabble.com/Class-method-or-Object-method--tp21732 172p21734327.html
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: Class method or Object method?

in general, doing gymnastics to support IS-A syntax when you have a
HAS-A semantic is ill-advised.

On Thu, Jan 29, 2009 at 11:54 AM, kropotkin wrote:
>
> Hi
>
> In general is it better to use a class method or object method? E.g I have a
> class A which provides certain functionality. I just want to use one of its
> methods in another class B. Is it better to inistantiate class A and do and
> object call or just do A->myMethod() ? The method doesn't need a reference
> to itself passed in so from that point of view it doesn't matter
>
> Thanks
>
> Justin

but that isn't what you're asking, is it. If the method supports it,
I'd go with the class method, or even a direct call to it by name if I
know it isn't inherited:

A::myMethod()


--
"The only thing that separates us from the animals is tattoos" -- Drea Smith

Re: Class method or Object method?

On Thu, 29 Jan 2009, Steven Siebert wrote:
> On Thu, Jan 29, 2009 at 2:11 PM, kropotkin wrote:
> > class A is the Catalogue and B is the Cart. Usually they
> > are separate but I want to show a flag relating to the
> > basket/cart in the catalogue against each product.
> > Really I am putting the method in the Cart class because
> > it seems to logically belong there - for organisational
> > reasons. I see what you mean about coupling though. It
> > could get messy!
> >>>
> >>> In general is it better to use a class method or
> >>> object method? E.g I have a class A which provides
> >>> certain functionality. I just want to use one of its
> >>> methods in another class B. Is it better to
> >>> inistantiate class A and do and object call or just do
> >>> A->myMethod() ? The method doesn't need a reference to
> >>> itself passed in so from that point of view it doesn't
> >>> matter
>
> If this is the case, perhaps the cart should be a
> container for "PurchaseItem" objects which contain the
> essential data (ie price, weight) and behaviours
> (calcShippingCost(), calcTax(), getProductInfo() - the
> last which can pull the reference from your catalogue).
> Additional information about the PurchaseItem can be "lazy
> loaded" from the catalogue if needed (ie product
> description) to keep your PurchaseItem lite and
> purpose-oriented. As an added bonus, by containing the
> PurchaseItems within the cart you can easily provide
> convience methods to iterate over the collection for
> things like calculating the total weight, total price,
> etc.

Yes, it seems like from the perspective of a mod_perl handler
(this is the modperl list after all) that doing these as
objects would be better. Especially the cart, but also
the catalog, because you don't know if they'll ask you
to run another catalog using the same structure.

Class function calls should not be used for request-specific
data that persists, i.e. data stored in package scope,
especially in mod_perl, e.g. your cart contents. Because
the class scope data persists across requests, so it can get
confusing trying to sort out things if another customer gets
the next request. Objects are useful because they form
discrete containers of data in the blessed references that
represent unique entities of a particular class, and they
(typically) would not persist across requests unless you use
a persistent object storage mechanism that keeps them
straight.

Cognitively, a catalog should not contain the cart.
Maybe your application should be a sort of "view" controller
that contains references to both the catalog object (source of
product data) and the cart object (contains items they bought).

view object
/ \
catalog cart

Then, the view selects what items to display, and asks the
cart if it contains those items when deciding whether to
display the flag.

Mark

Re: Class method or Object method?

> the next request. Objects are useful because they form
> discrete containers of data in the blessed references that
> represent unique entities of a particular class, and they
> (typically) would not persist across requests unless you use
> a persistent object storage mechanism that keeps them
> straight.

This isn't quite informative. But objects also make it easier
to inter-relate a bunch of methods that you haven't necessarily
programmed yet without having to remember what arguments you
have to pass around from method to method, because you can get
them out of $self when you need them in whatever routine. That,
I would say, is the biggest benefit (to me) for being strict
about using object structure whenever it makes sense.

Mark

Re: Class method or Object method?

--0015175cdf6afd86c30461a4ea10
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

>
>
> This isn't quite informative. But objects also make it easier
>> to inter-relate a bunch of methods that you haven't necessarily
>> programmed yet without having to remember what arguments you
>> have to pass around from method to method, because you can get
>> them out of $self when you need them in whatever routine. That,
>> I would say, is the biggest benefit (to me) for being strict
>> about using object structure whenever it makes sense.
>>
>
> Mark
>

Agreed, this is a definite benefit during development. But the objects give
you an additional, foundational, benefit...it's easier to understand what it
is your doing. By separating your domain 'artifacts' into logical objects,
similar to how they would exist in real life, it is easier to understand a
complex model because it's easier can comprehend the individual abstract
parts. Further, adding logical behaviours to these instantiated objects
(both static and instance) you can expect a set of behaviours from that
object (it's interface), depending on what it is and where in the
inheritance taxonomy it falls. This, of course, is very important when you
start inter-relating (coupling) objects into coherent components...and even
more so when you come back in 6 months and have to add in a similar but
ever-so-slightly-different object =). OOP, especially the perl way, give
you lots of flexibility...but as you suggested, we have to make the decision
when OOP is the right thing to after analyzing all aspects of the project.

I agree that the catalouge, in our limited understanding of the
requirements, should be a class (perhaps an object, depending on if there is
an fact a current or future business need to have multiple
catalogues...sometimes, you're only going to represent a single library).
Also about the importance of understanding the way mod_perl handles
persistance...which can bite you when your not paying attention.

S

--0015175cdf6afd86c30461a4ea10
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Re: Class method or Object method?

Hi Steven

Not quite. From the catalogue I want to see what is in the user's cart. As
they browse the catalogue they will see a flag next to each item if it is
in the basket; 'n already in your basket' sort of thing.

So from the class which produces catalogue pages I want to be able to obtain
information about the contents of this user's basket. You may say,
instantiate the basket class from the catalogue class and in many ways this
seems the simplest. I haven't done this because the both classes are part of
a framework. Basket does not have a constructor of its own but a method
which constructs it as part of the framework - I think what I probably need
is to create a new class which both these can use.

Thanks for all your help

Justin





Steven Siebert wrote:
>
> If I am reading your situation correctly, you want to be able to
> reference the catalogue for product information from the cart?
>
> If this is the case, perhaps the cart should be a container for
> "PurchaseItem" objects which contain the essential data (ie price,
> weight) and behaviours (calcShippingCost(), calcTax(),
> getProductInfo() - the last which can pull the reference from your
> catalogue). Additional information about the PurchaseItem can be
> "lazy loaded" from the catalogue if needed (ie product description) to
> keep your PurchaseItem lite and purpose-oriented. As an added bonus,
> by containing the PurchaseItems within the cart you can easily provide
> convience methods to iterate over the collection for things like
> calculating the total weight, total price, etc.
>
> Regards,
>
> S
>
> On Thu, Jan 29, 2009 at 2:11 PM, kropotkin
> wrote:
>>
>> Hi Steven
>>
>> The method doesn't effect the state of anything . It just returns some
>> information. The context is:
>> class A is the Catalogue and B is the Cart. Usually they are separate but
>> I
>> want to show a flag relating to the basket/cart in the catalogue against
>> each product. Really I am putting the method in the Cart class because it
>> seems to logically belong there - for organisational reasons. I see what
>> you
>> mean about coupling though. It could get messy!
>>
>> Regards
>>
>> Kropotkin
>>
>>
>>
>>
>>
>> Steven Siebert wrote:
>>>
>>> It depends. (always the expected answer with an OOP design question =)
>>>
>>> Generally, if the method you are calling on class A does not work
>>> on/effect the state of a specific object, its a canidate to be a
>>> static (class) method. However, you should be careful about coupling
>>> your objects and understand what you are doing when you do. If you
>>> feel comfortable for that method be a static method, though, you're
>>> probably good to do so. Generally....depending....
>>>
>>> =)
>>>
>>> Hope this helps.
>>>
>>> Steve
>>>
>>> On Thu, Jan 29, 2009 at 12:54 PM, kropotkin
>>> wrote:
>>>>
>>>> Hi
>>>>
>>>> In general is it better to use a class method or object method? E.g I
>>>> have a
>>>> class A which provides certain functionality. I just want to use one of
>>>> its
>>>> methods in another class B. Is it better to inistantiate class A and do
>>>> and
>>>> object call or just do A->myMethod() ? The method doesn't need a
>>>> reference
>>>> to itself passed in so from that point of view it doesn't matter
>>>>
>>>> Thanks
>>>>
>>>> Justin
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Class-method-or-Object-method--tp21732 172p21732172.html
>>>> Sent from the mod_perl - General mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Class-method-or-Object-method--tp21732 172p21733697.html
>> Sent from the mod_perl - General mailing list archive at Nabble.com.
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Class-method-or-Object-method--tp21732 172p21735936.html
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: Class method or Object method?

kropotkin wrote:
> Hi Steven
>
> Not quite. From the catalogue I want to see what is in the user's cart. As
> they browse the catalogue they will see a flag next to each item if it is
> in the basket; 'n already in your basket' sort of thing.
>
> So from the class which produces catalogue pages I want to be able to obtain
> information about the contents of this user's basket. You may say,
> instantiate the basket class from the catalogue class and in many ways this
> seems the simplest. I haven't done this because the both classes are part of
> a framework. Basket does not have a constructor of its own but a method
> which constructs it as part of the framework - I think what I probably need
> is to create a new class which both these can use.
>
I don't think you need a delegator.

Store the 'global' cart (which is part of the user which is part of the
session) in the execution environment/scope.

The catalog code might say

GLOBALREQUEST->current_session->current_user->current_cart-> is_in_cart('thisitem')

I have encountered this 'back call into execution context' a few times.
Generally to me this means you have a singleton pattern.

In a short concise code expression:

package Cart;
my $instance;
sub new { return $instance ||= bless {}, $self }
sub is_in_cart { ... }

package Catalog;
sub show_flag {
my $self = shift;
Cart->new->is_in_cart(shift);
}

The function new on Cart returns any already created instance if it
exists and creates a new one if not.

The package Catalog merely calls Cart->new when it wants a Cart, without
having to worry about whether or not there is an instance of it yet or
not (Cart class's problem) - since the same instance is returned on
every call to new, that makes the Cart a singleton. It can be accessed
from anywhere in the interpreter that has access to the Cart namespace
by a static call to Cart->new

This lets you do things like lazy-create a cart object only when needed,
and if there can't be a cart object for whatever reason you can use the
Nothing/Null pattern - return an object that, to its interface, looks
like a cart (same methods) but putting something into it is a noop and
getting its list of contents is always an empty set... thus avoiding
constantly checking to see if the object is not available in your code.

I'm babbling aren't I.

David

Re: Class method or Object method?

On Thu, 29 Jan 2009, David Ihnen wrote:
>
> I have encountered this 'back call into execution context' a few times.
> Generally to me this means you have a singleton pattern.
>
> In a short concise code expression:
>
> package Cart;
> my $instance;
> sub new { return $instance ||= bless {}, $self }
> sub is_in_cart { ... }
>
> package Catalog;
> sub show_flag {
> my $self = shift;
> Cart->new->is_in_cart(shift);
> }
>
> The function new on Cart returns any already created instance if it exists and
> creates a new one if not.
> The package Catalog merely calls Cart->new when it wants a Cart, without
> having to worry about whether or not there is an instance of it yet or not
> (Cart class's problem) - since the same instance is returned on every call to
> new, that makes the Cart a singleton. It can be accessed from anywhere in the
> interpreter that has access to the Cart namespace by a static call to
> Cart->new

Under mod_perl, doesn't that mean that if user A is the
first to hit an interpreter and the cart instance is created
for them, then if user B's request is the next to be served
by the mod_perl child, that user B will get user A's cart?

Mark

Re: Class method or Object method?

Mark Hedges wrote:

>> package Cart;
>> my $instance;
>> sub new { return $instance ||= bless {}, $self }
>> sub is_in_cart { ... }

> Under mod_perl, doesn't that mean that if user A is the
> first to hit an interpreter and the cart instance is created
> for them, then if user B's request is the next to be served
> by the mod_perl child, that user B will get user A's cart?

Yes. mod_perl (or any persistent Perl framework) doesn't clear out globals or package variables when
the request is done. And in this case, $instance is a package variable.
If that's what you want, then it's a valid way to implement it (usually called a Singleton pattern).

--
Michael Peters
Plus Three, LP